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ABSTRACT 

The United States Marine Corps is explonng the concepts of Operational 
Maneuver From the Sea (OMFTS) and Ship-To-Objective Maneuver (STOM) as 
methods for employment of maritime forces in the future. At the same time, the 
Department of Defense (DoD) is pursuing the acquisition of the Joint Tactical Radio 
System (JTRS), a multi-band, multi-channel, multi-mode family of radios, designed to 
form self-organizing, self-healing communications networks. The JTRS will have to 
support Marine forces in combat at long distances from the forces’ support and higher 
headquarters units. This extended range will require the use of relay radios in order to 
maintain connectivity between the attacking force and its support. 

This thesis explores the relay station bandwidth requirements to support Marine 
forces. The question is analyzed through the use of a discrete-event simulation written in 
Java, which models the behavior of a JTRS network in a STOM scenario. Quality of 
service of the communication network is measured by timely delivery of messages. 

The results of the simulation indicate that the JTRS network performance is 
insensitive to relay station bandwidth. Rather, the subordinate headquarters involved in 


the scenario were the most overloaded nodes tn the network. 
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The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government. 

The reader is cautioned that computer programs developed in this research may 
not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the programs are free of computational and logic 
errors, they cannot be considered validated. Any application of these programs without 


additional verification is at the nsk of the user. 
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EXECUTIVE SUMMARY 


The United States Marine Corps is exploring the concepts of Operational 
Maneuver From the Sea (OMFTS) and Ship-To-Objective Maneuver (STOM) as 
methods for employment of maritime forces in the future. At the same time the 
Department of Defense (DoD) is pursuing the acquisition of the Joint Tactical Radio 
System (JTRS), a multi-band, multi-channel, multi-mode family of radios, designed to 
form self-organizing, self-healing communications networks. The JTRS offers great 
advances in communication technologies for use in OMFTS. 

JTRS is currently in Phase 1, Program Definition and Risk Reduction (PDRR), of 
the acquisition process. This phase is intended to describe the exact requirements for a 
system and to identify low risk paths to reach those requirements. The bandwidth 
requirements of the relay suite for the JTRS have not yet been specified. It 1s critical to 
correctly specify these requirements because the JTRS will support Marine forces 
involved in OMFTS and STOM at long distances from the forces’ support and higher 
headquarters units. This extended range will require the extensive use of relay radios in 
order to maintain connectivity between the attacking force and its support. 

This thesis explores the relay station bandwidth requirements to support Marine 
forces in STOM. The question is analyzed through the use of a discrete-event simulation 
written in Java, which models the behavior of a JTRS network in a STOM scenario. 

The simulation developed moves JTRS units around a simulated battlefield. ‚As 
each JTRS moves through the sımulation ıt generates messages. The arrıval of messages 
1s viewed as a Poisson process. The frequency and priority of these messages changes 
when the tactical situation of the JTRS changes. 

Generated messages then pass through the JTRS network until they reach their 
intended recipient. Messages flow through the network following a few simple rules. 
The two most important of these rules are: a radio in direct contact with the target of a 
message will always send it to the target, and a radio not in contact with the message's 


target will send the message to a randomly selected radio with which it is in contact 


XIX 


When a message 1s generated 1ts priority determines how long the system has to 
deliver the message to its recipient. A message that is not delivered in less than that time 
is considered late. The characteristic of JTRS network selected for evaluation 1s timely 
delivery of messages. This characteristic is measured by a penalty function that penalizes 
the system for late delivery of messages. The penalty for lateness of a particular message 
is weighted by the prionty of that message. 

The scenario used in the simulation is an example of STOM against two 
Objectives. The main Objective is located 125 miles inland and is attacked by two 
battalions. A supporting attack of one battalion is sent against another objective that 1s 30 
nautical miles inland. The regimental headquarters remains aboard amphibious shipping, 
located 50 nautical miles from shore. The range across which the attacking force must 
maintain communication is up to 175 nautical miles. 

The simulation was run for 20 iterations each under several relay bandwidth 
capacities. The results of the simulation indicate that the JTRS network performance 1s 
insensitive to relay station bandwidth. It is possible that the result may stem from the 
simplistic rules that the model uses to route messages through the network. Although the 
result is surprising, analysis of a simplified special case of the scenario shows that the 
expected number of messages flowing through the battalions’ headquarters is 
significantly more than the expected number flowing through a relay station. This 
analysis suggests that the bandwidth of the battalion headquarters is the true limiting 
parameter in a JTRS network. 
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E INTRODUCTION 


As we enter the 21 Century, the pace of technological change is accelerating at 
an exceptionally rapid rate. From on-line shopping and stock trading, to improved 
missile guidance systems, to the ubiquitous cellular phone and pager, the results and 
possibilities of new applications of technology are all around us. The ongoing 
development of technology offers opportunities to both the United States and potential 
adversaries throughout the world. 

The Marine Corps has applied great effort and thought into preparing to fight and 
win the future battles of the nation. Marine Corps Doctrinal Publication 1 (MCDP 1), 
Warfighting [Ref. 1] explains that, although the nature of war - a struggle between two 
independent and hostile wills - will not change, the methods used to achieve victory will. 
Therefore, a critical part of our preparation is considering the likely effects of technology 
on the conduct of war. 

The acquisition of the MV-22 Osprey tilt-rotor aircraft and the Advanced 
Amphibious Assault Vehicle (AAAV) will give the Marine operating forces of the future 
a huge increase in range, speed and flexibility in the execution of amphibious operations. 
Extensive thought on the efficient use of this increased capability has led to two Manne 
Corps Concept Papers. The Operational Maneuver from the Sea (OMFTS) Concept 
Paper [Ref. 2] describes the tenets and principles that will drive maritime power 
projection in the future. The Ship-To-Objective Maneuver (STOM) Concept Paper [Ref. 
3] describes, at the tactical level of war, how the concept of OMFTS will be implemented 
by the Marine Corps of the future. The STOM Concept Paper addresses the effects of 
technology as follows. 

Emerging technologies represented by the Advanced Amphibious 

Assault Vehicle (AAAV), MV-22 aircraft, global positioning system 

(GPS), and developing command and control systems will radically alter 

the nature of amphibious operations. Landing force units will possess 

their own mobility systems — and have the ability to independently 

navigate across the ocean surface to penetrate the enemy's shoreline at 


points of their choosing... This combination of maneuver warfare 


philosophy and emerging technologies will provide the naval force with 


enhanced combat effectiveness. [Ref. 3] 


The capabilities of current systems and procedures to support operations will be 
surpassed by the demands of executing OMFTS and STOM. The shortcomings of 
existing systems is not surprising because current systems and procedures were designed 
to support Marines as they fight today, not as we expect them to fight in the future. For 
example, current logistic systems in the Marine Corps cannot support a force engaged in 
combat at the extended distances envisioned by OMFTS. Equally important, current C4] 
systems do not have the ability to maintain the required connectivity with the assault 
force. Once the rapidly moving force starts its movement to the objective, it will quickly 
outstrip the range of existing communication systems. 

In current-day operations a Marine force conducting an amphibious operation 
must first establish itself ashore, build a logistic support area, establish terrestrial satellite 
communication stations, and then move to the objective. The OMFTS concept does not 
allow an operational pause at the beachhead, and so cannot initially rely on satellite 
communication for its long-haul, high bandwidth communication backbone. Only after 
the objective has been secured will the landing force have the security and time to set up 
satellite communications equipment. Until that time, C4I requirements will be met by 
organic, mobile C4I assets and retransmission or relay platforms. 

The Marine Corps Combat Development Process ıs designed to ensure that the 
requirements of the operating forces are met. In support of OMFTS, the Requirements 
Division of the Marine Corps Combat Development Command (MCCDC) has developed 
a Long-Term C4I Architecture. There are many uses of emerging technology in this 
proposed architecture, but no technology is more critical than the Joint Tactical Radio 
System (JTRS). This thesis looks at the question of JTRS relay suite bandwidth 


sufficiency through the use of a discrete-event simulation. 


A. JOINT TACTICAL RADIO SYSTEM 


The JTRS 1s planned to be a multi-channel, multi-mode (voice, video, data), 
multi-band (2-2000MHz) family of radios to support the increased bandwidth and 
networking requirements of the warfighter of the future. The JTRS, as envisioned, will 
create a self-organizing, self-healing, network that will provide the high bandwidth C4I 
backbone for the Marine Air Ground Task Force (MAGTTF) of the year 2015. In effect, 
the JTRS will be the backbone of a robust, high speed, digital Wide Area Network 
(WAN) that connects the Wireless Local Area Networks (WLANSs) of subordinate units. 
Each WLAN will have one or more JTRS radios which act as gateways to the MAGTF 
WAN. 

The Operational Requirements Document (ORD) [Ref. 4] for the JTRS has been 
published, and defines many requirements for the radio system. While the ORD does 
define data-rate requirements for specific band, mode, and radio configuration 
combinations, 1t does not specify what the throughput capabilities of the communications 
relay suite should be. This is a critical question which needs to be answered in order to 
ensure that the C4I needs of the Marine Corps are met in STOM. 

The JTRS is in Phase 1 of the acquisition process, known as Program Definition 
and Risk Reduction, in which the desired operational capabilities of the system are 
described. As shown in the book Modeling Complex Computer and Communication 
Systems [Ref. 5], the cost to correct design errors and incorporate design changes goes up 
by orders of magnitude as the project advances toward completion. These costs increases 
are indicated by the graph in Figure 1. 

It can be seen, therefore, that it 1s vitally important to specify the true 
requirements of the JTRS as accurately as possible and as early in the development 
process as possible. Early and correct specification will provide the Marine Corps with 
equipment that meets its needs, and will avoid the large costs resulting from the late 


addition to required capabilities. 
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Figure 1. Relative cost of errors as related to phase of development. After [Ref 5] 


B. PURPOSE 


The purpose of this thesis is to analyze the bandwidth required for the JTRS relay 
Suite to support United States Marine Corps forces ashore during amphibious operations 
in the year 2015. The nature of the technologies that will be incorporated into the 
MAGTF C4I Architecture is largely unknown at this time. Also unknown is the true 
current bandwidth requirements of Marine forces using today’s equipment and doctrine. 

This thesis develops a simulation to estimate the performance of the JTRS, given 
a combat scenario and a set of parameters describing the JTRS performance. This tool 
will allow the Marine Corps to identify, early in the combat development process, the 
likely bandwidth requirements that the JTRS must meet. In particular, the question of 
how much JTRS bandwidth is required to support STOM operations is examined. 

In the absence of a working JTRS network, a model of the JTRS portion of the 
future MAGTF CAI Architecture must be built. This model must be complex enough to 


model the expected behavior of the JTRS and flexible enough to adapt in the event of 
changes to the operating charactenstics of the JTRS. 

Once an appropriate model is developed, measures of effectiveness (MOEs) must 
be defined. The choice of MOEs to evaluate a system that does not exist, and which is 
designed to support doctrine that has never been exercised, is problematic at best. 
Fortunately, the JTRS is designed to fulfill a function for which there is a current analog 
in digital networks. The JTRS can thus be effectively evaluated using the same MOEs 
that are appropriate for current communications systems and computer networks. 
Although the methods, capabilities and technologies employed by the JTRS will be far 
different from the currently fielded systems, its purpose remains the same. 

The characteristic of the JTRS network selected for evaluation is the timely 
delivery of messages. This characteristic is measured by a weighted penalty function 
based on the number of messages that arrive late to their destination and the pnonty of 
those messages. The penalty function, then, is the MOE for the JTRS network. In this 
situation a lower MOE score is better, as it reflects fewer late message deliveries. The 
penalty function is more fully descnbed in Chapter IV. 

A secondary measure of effectiveness for the JTRS is the number of relay sites 
required to support the landing force. The minimum number of relay sites to support an 
operation is heavily dependent on the scenario examined. In the simplest case of one 
headquarters and one maneuver element, the number of relay sites required is simply the 
number required to span the maximum distance separation between the headquarters and 
its subordinate unit. In more complicated scenarios, those with multiple maneuver 
elements, the number of relay sites will go up, depending on the scenano examined. 
However, regardless of the topology of the network, this MOE is only a function of the 
range of the communication systems being used. Of interest however is the behavior of 
the network when additional relay sites are placed ın parallel along the communications 
path. The effects of additional parallel relay sites can be examined using the Penalty 


Function. 


C. METHODOLOGY 


This thesis will model the MAGTF C4I system using a discrete-event simulation 
and will employ the software package Simkit to implement the model. Analysis of the 
system simulation will be conducted using the statistics gathering features of Simkit. 
JTRS system parameters and scenario parameters will be varied to gain insight into the 


critical threshold requirements of the JTRS. 


D. THESIS ORGANIZATION 


The remainder of this thesis is organized as follows. Chapter II describes the 
background of the doctrinal and technical changes leading to this thesis. Chapter III 
describes the discrete-event simulation approach in general and Simkit in particular. 
Chapter IV describes the model developed for this thesis, it’s MOEs, and the scenario 
used to demonstrate the model. Chapter V contains the scenario results. Chapter VI 
contains conclusions and a recommendation and identifies areas for further research and 


improvement of the model. 


II. BACKGROUND 


An appreciation of the doctrine supporting and directing Marıne Corps forces in 
the year 2015 aids in understanding the nature of problem addressed in this thesis. Also 
important ıs an understanding of the lıkely employment of the JTRS in support of this 
doctrine as envisioned in the Marine Corps Long-Term C4I Architecture. 

There are unique challenges in modeling a communication system that has not yet 
been completely specified. This modeling effort 1s made doubly hard by the fact that the 
Marine Corps cannot even quantify current bandwidth requirements, due to a paucity of 
communications traffic data. Therefore, it is critical to understand the fundamental 
concepts of OMFTS and STOM, which are discussed next. Following that, the JTRS and 
the Marine Corps Long-Term C4I Architecture are addressed. The chapter concludes 
with a discussion of the lack of communications data, and the steps being taken to 


mitigate the problem. 
A. OPERATIONAL MANEUVER FROM THE SEA 


The information in this section 1s drawn entirely from the Marne Corps Concept 
Paper, Operational Maneuver From The Sea [Ref. 2]. Although almost four years old, 
the OMFTS Concept Paper remains the key document used to descnbe how the Marine 
Corps will apply maneuver warfare to amphibious operations and take advantage of 
technological changes occurring now and in the future. 

The OMFTS Concept Paper 1s subtitled “A Concept for the Proj ection of Naval 
Power Ashore” and it makes a strong case for America’s need for a “...credible, 
forwardly deployable power projection capability.” [Ref. 2] This forwardly deployable 
force must have a“... forcible entry capability that is independent of forward staging 
bases, friendly borders, overflight nghts, and other politically dependent support.” These 
needs point to U.S. naval forces (U.S. Navy and U.S. Marine Corps) with the strength to 
deal with any hostile action, be that action a natural disaster or enemy military activity, 


and the flexibility to do so at any time in any location. 


The OMFTS Concept Paper describes the nature of the threats the Marine Corps 
expects to meet in the 21° Century, the response to those threats and the path which must 
followed to be able to have the proper response to future threats. The threats of the future 
cannot be known, but the trends of today can be projected forward to give hints about the 
enemies the United States and her Marine Corps will face. The OMFTS Concept Paper 
predicts three general threats to American security. 

The first of these threats 1s the rise in non-state fighters, those fighting for their 
religion, tribe, or ethnic group, but not associated with a particular nation state. While 
the world has had such fighters throughout history, the OMFTS Concept Paper predicts 
an increase in their numbers and activities in the evolving political scene. 

The second general area of threat is the developing regional powers. These 
powers are defined as nations with strong militaries that can dominate their neighboring 
states politically, militarily, or economically. OMFTS makes the point that not all of 
these regional powers will be threats to the security of the United States. Some of these 
regional powers will be hostile and some will be friendly, but all will have the ability to 
threaten the security of the United States. 

These two threats can be seen as a result of the end of the cold war and the fall of 
the Soviet Union. The collapse of the Soviet Union left the United States as the only 
superpower in the world. The third threat, and the most unknown, 1s the next 
superpower. History shows that a single dominant power remains dominant only for a 
limited time; eventually some new power arises to threaten the dominance. Accepting 
that America will have a rival superpower some time in the future does not tell us 
anything about that superpower. Such a superpower could be a current state, a new state 
we are unfamiliar with, or an alliance of states. The important assumption is that there 
will eventually be a superpower threat to American interests and the Marine Corps must 
be ready to meet that threat. 

In order to meet these threats, OMFTS has six defining characteristics. These are 
that Operational Maneuver From The Sea: 

1. Focuses on an operational objective. 


2. Uses the sea as maneuver space. 


3. Generates overwhelming tempo and momentum. 
4. Pıts strength against weakness 
5. Emphasizes intelligence, deceptions, and flexibility. 


6. Integrates all organic, joint, and combined assets. [Ref.2] 


Figure 2, drawn from an OMFTS brief given by MCCDC [Ref. 6], depicts a 
notional example of OMFTS. Notice that this example focuses on an operational 
objective and uses the sea as maneuver space. Also note the huge distances to be crossed 
and communicated over. 

The concepts dealt with in OMFTS define the way ahead for the Manne Corps. 
In defining required capabilities, the OMFTS Concept Paper has this to say about 
Command and Control: 

The command and control system best suited to OMFTS will be very 
different from those developed to deal with previous approaches to amphibious 
warfare. Techniques previously employed to compensate for the inability of fire 
support units to see the battlefield will give way to techniques that exploit the fact 
that combatant units will be better informed than ever before. Communications 
systems designed to provide a few headquarters with an overall view of the 
situation will have to be replaced by those that provide units with control over the 
information they need. [Ref. 2] 

The STOM Concept Paper calls the OMFTS Concept Paper the “capstone Marine 
Corps Concept Paper.” [Ref. 3] As the capstone, the OMFTS Concept Paper serves as 
the master plan for how the Marine Corps approaches the challenges of the future. By 
necessity the OMFTS Concept Paper is broad and somewhat vague, dealing with topics 
as seemingly unconnected as the nature of the threat in the 21“ century, training and 
education, and command and control. The job of filling in the details is left to other 


Marine Corps Concept Papers. 
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Figure 2. An illustration of OMFTS. From Ref. [6]. 


B. SHIP-TO-OBJECTIVE MANEUVER 


The background section of the STOM Concept Paper itself provides the best 
possible description of its purpose. 
Emerging technologies represented by the Advanced Amphibious 
Assault Vehicle, MV-22 aircraft, global positioning system (GPS), and 
developing command and control systems will radically alter the nature of 
amphibious operations. Landing forces will have their own mobility 
systems — and have the ability to independently navigate across the ocean 
surface to penetrate the enemy’s shoreline at points of their 
choosing.... These new capabilities will enable tactical commanders to 
make decisions as the situation develops to exploit enemy weaknesses and 


maintain the momentum of the attack from the ship to the objective. ... This 
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paper, Ship-To-Objective Maneuver, describes this new tactical concept 


for conducting amphibious forcible entry. [Ref. 3] 


STOM seeks to apply the six key elements of OMFTS to the tactical execution of 
amphibious operations. STOM has distilled 1ts own purpose as follows. 

1. Control tempo/overwhelm adversary. 

2. Combined arms maneuver from over the horizon (OTH). 

3. Dilute the enemy by enlarging battlespace. 

4. Control vital area by fighting outside it. 

5. Maneuver to cause and exploitable reaction. [Ref. 3] 

STOM ıs best described graphically. The remainder of this section will use 
various figures, along with discussion of STOM terms and concepts drawn from the 
STOM Concept Paper. 

Figure 3, drawn from the MCCDC Concepts Division's Marine Corps 
Warfighting Concepts for the 21° Century Brief [Ref. 7] shows the difference between 
today’s reality and tomorrows ıdeal. The Amphibious Task Force (ATF) consisting of at 
least U.S. Navy and U.S. Marine forces, and also possibly joint and multinational forces, 
launches an operation against a threat located at the objective (OBJ). Today, all Marine 
forces converge and establish a Force Beach Head Line (FBHL) in order to allow 
supplies and follow-on forces to be brought into the Beach Support Area (BSA). Only 
after this buildup and consolidation can the force move forward to seize the objective. 
This buildup will be avoided in the future. Under concept of STOM, maneuver forces 
will move directly to their objectives, following the path of least resistance, in order to 
maintain their combat power for the decisive action at the objective 

Figure 4 shows the mobility assets that will make STOM possible. The entire 
concept of STOM relies on these three vehicles, the AAAV, the MV-22 , and the Landing 
Craft Air Cushioned (LCAC), collectively referred to throughout the Marine Corps as 
“the tnad.” These vehicles will increase the striking range of the MAGTF from where it 
is today to the distances shown in this figure. Note that the objective could be an 


additional 100-200 Nautical Miles (NM) from the shore. 
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Figure 4. Depiction of aSTOM operation. From [Ref. 6]. 
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The STOM Concept Paper sets forth the lexıcon for future amphibious operations 
and attempts to add valid tactics to the Marine Corps leader's set of skills. The ideas of 
STOM are supported by the triad of AAAV, MV-22, and LCAC. In order for these 
concepts to work, the command and control systems of the future must evolve to support 
STOM. The concept paper recognizes this and says the following. 

Command and control provide the mechanism by which a 

commander recognizes what needs to be done and communicates those 

actions required to ensure mission accomplishment... Command and 

control systems must provide landing force commanders at all echelons a 

common operational picture and the connectivity to monitor execution and 

to influence events when necessary. 


[Ref. 3] 


The STOM Concept Paper indicates that there is an understanding among the 
Marine Corps leadership that the mobility triad alone is not enough to enable the Marine 
Corps to execute OMFTS and STOM. It is clear that that today's C4I system must 
evolve into a more flexible and capable system to support the types of operations we plan 


to conduct. 
C. JOINT TACTICAL RADIO SYSTEM 


The majority of the information contained in this section comes from the JTRS 
JPO website [Ref. 8]. Because thıs ıs an active acquisition program, JTRS may be forced 
to change to adapt to developing technology or because of the limitations of technology. 
Despite this uncertainty, the basic facts presented here have remained unchanged since 
the Mission Needs Statement (MNS) [Ref. 9] for JTRS was written in 1997. 

JTRS will be an open architecture, software programmable system. This will 
allow future upgrades as the state of the art advances. The fact that it 1s software 
programmable will speed the upgrade process when it becomes necessary. This 1s a step 


beyond the traditional hardware-based digital radio of the current force. [Ref. 9] 
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JTRS will provide both line-of-sight and beyond-line-of-sight capabilities and 
will operate from 2-2000 MHz. JIRS will transmit voice, video and data. The 
waveforms required to meet this requirement have not been chosen, but this wide range 
of capabilities will put JTRS far ahead of any existing radio system. 

JTRS will be a family of radios. This family will provide communications for 
ground units, ships, and aircraft. The different domains will require different radios to 
perform their missions, but by relying on the common open architecture, all members of 
the family will be able to share waveform software and will remain interoperable. [Ref. 
8] 

By providing voice, video, and data transmission from 2-2000 MHz across the 
full spectrum of users on an upgradeable platform, JTRS can claim to be the “DoD radio 


of the future.” [Ref. 8] 


D. USMC C41 LONG-TERM ARCHITECTURE IN SUPPORT OF STOM 


The USMC C4I Long-Term Architecture 1s the umbrella term for the efforts that 
have gone into describing the architecture that will support Marine forces conducting 
OMFTS and STOM. Itis in fact not the next generation architecture, but rather the 
architecture-after-next. 

The paper, “Overview of the Proposed 2010 Command, Control, Communication, 
Computers, Intelligence and Reconnaissance (C4ISR) Architecture for the Marine Corps” 
(Ref. 10], produced by the C4ISR Architecture Branch of the Requirements Division of 
MCCDC, provides the most accessible description of the probable attributes of the 
architecture-after-next. The paper’s abstract in its entirety is as follows. 

This paper briefly outlines the draft Marine Corps communications 
architecture for the year 2010. This architecture is characterized by 

numerous low-power wireless local area networks tied together by a self- 


organizing backbone of Joint Tactical Radio Systems radios. [Ref. 10] 


This architecture is seen in Figure 5. Note that JTRS wide area network (WAN) 
is made up of JTRS nodes linking the wireless local area networks (WLANs) of 


subordinate units. Figure 5 also depicts the use of relays to maintain the network. These 


relays may be on the ground or airborne. 
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Figure 5. Notional MAGTF C4I architecture in 2010. From [Ref. 10]. 


E. DATA USED IN THIS THESIS 


The Marine Corps has not accurately quantified the bandwidth 1t requires to 
conduct combat operations today, let alone in fifteen years. Extensive work has been 
done by Raytheon Systems Company in modeling the USMC Regiment and Below 
Architecture, specifically looking at the Near Term C4I Architecture of the Marine 
Corps. According to a MCCDC brief to the JTRS Joint Program Officer (JPO) [Ref. 11]: 
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l Detailed C2 traffic load information does not exist. . 

2. Digitization and doctrine are still relatively new. 

3. No collection of detailed traffic during actual deployment of systems has 
occurred. 

4. Load Method used by Raytheon System ıs based on “Best Engineering 


Judgment.” 


The result of this Raytheon simulation study, the USMC Communications 
Architecture Study: Final Report [Ref. 12] details the attempts made by the analysts to 
determine communication loads for the simulation. The study used the Marine Corps 
Message Event Occurrence (MEO) database. The MEO lists Marine Corps Operating 
Facilities (OPF AC), which can be described as the command and control nodes of the 
force. For each OPFAC the MEO database contains a listing of the type of messages that 
particular OPFAC might send to any other OPFAC. 

The MEO database does not describe the frequency of any message type. In the 
case of the Raytheon study, the analysts used their best Judgment to determine the 
estimated number of times a particular message might occur in a given time period of the 
simulation. Similarly, the voice load of the network was simulated by a message 
generator that produced messages which have an exponentially distribute length, with a 
mean length of eight seconds. The frequency of voice transmissions was determined by 
setting voice load as a percentage of available bandwidth, varying by the phase of the 
simulation. While these are all defendable and required assumptions of the model, they 
point to the lack of precision in the description of the Marine Corps’ bandwidth usage. 

It will be very difficult for the Marine Corps to take the steps to predict future 
bandwidth utilization until current utilization 1s identified. New C4I systems are planned 
to add capability to the MAGTF. Similarly, some current systems will be phased out of 
Service as new equipment is fielded. In order to predict future bandwidth requirements it 
is necessary to first identify current requirements and second to adjust that requirement 
by the anticipated changes to bandwidth requirements caused by the addition and deletion 


of specific C4I systems. 
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The traffic load question ıs a large challenge, and on the surface ıt may appear 
that the desired result cannot be attained. Fortunately, the Marine Corps is committed to 
improving our understanding of bandwidth requirements for the force of the future, and is 
continuing to develop the tools and metrics to quantify those requirements. MCCDC is 
funding Raytheon to further develop the Regimental Landing Team Mid-Level Fidelity 
Simulation Scenario. The results of this simulation, along with expected updates as 
architecture changes over the course of time, will provide a solid measure of the 
bandwidth requirements of USMC forces in a broad range of operations. 

This thesis will analyze the relay problem by developing a discrete-event 
simulation model that incorporates the key distance, bandwidth, and C4] load issues 
involved in STOM. The approach taken in the absence of empincal traffic size and 
frequency data 1s to provide notional message data for this thesis. Message size and 
inter-arrival times are treated as random variables and are assigned distributions. As the 
Marine Corps continues to explore the area of traffic analysis, data will become available. 
Those data, based on the Regimental Landing Team Mid-Level Fidelity Simulation 


Scenario, will further improve the validity of the model output. 


THIS PAGE INTENTIONALLY LEFT BLANK 
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III... DISCRETE-EVENT SIMULATION AND SIMKIT 


This chapter opens with a discussion of the reasons for selecting a discrete-event 
simulation as the method to be used to analyze the JTRS radio network in support of 
Marine Forces of the future. The chapter continues with an overview of discrete-event 
simulations, in order to aid in the reader's understanding of Chapter IV's description of 
the model. The chapter concludes with an introduction to Simkit, the program used to 


formulate the simulation. 
an DISCRETE-EVENT SIMULATION 


Figure 6, drawn from Simulation Modeling & Analysis [Ref. 13], broadly depicts 
the methods that can be used to study a system. Each descending tier, reading from left 
to right, adds to the degree of abstraction. In the case of the JTRS, the lack of an existing 
system precludes experimentation with the actual system. The mathematical and 
analytical training of the operations researcher lead to a greater preference for, and ability 
with, building a mathematical model rather than constructing a physical model. Finally, a 
complex stochastic system, such as a military communication network, does not lend 
itself to analytical solution, thus leaving simulation as the preferred method to study the 
problem. This thesis will therefore use the discrete-event approach to simulation. 

Simulation Modeling & Analysis [Ref. 13] describes the discrete-event lien 
method as follows. “Discrete-event simulation concerns the modeling of a system as 1t 
evolves over time by a representation in which the state variables change instantaneously 
at separate points in time.” [Ref. 13] The status of the system 1s tracked over the course 
of the simulation by the state variables of the system, an event list, and use of a 
simulation clock. It is possible to advance through the simulation either by time-step of 
by event-step. This thesis will use the event-step method of discrete-event simulation. 

State variables are those elements of the model of the system that change over 


time and describe the functioning, performance or abilities of the system. The values of 
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the state variables at any given time completely describe the system being simulated. 
That 1s to say that each element of the set consisting of all possible combinations of 
values of the state vanables describes a particular state of the system as a whole. From 
this it follows that the only way to change the system is to change one or more of the 
state variables, thus transitioning to a new element of the set of possible values and so 
describing a new state of the system. State variables make instantaneous changes at 
discrete points in time, remaining fixed between these instantaneous changes rather than 


changing continuously. 


Hi TEN with Experiment with a 
actual system mode] of the 
system 


Physical mode] Mathematical model] | 


Analytical solution | Simulation 


Figure 6. Ways to study a system. After [Ref. 13] 


The event list 1s simply a time-sequenced list of all future events scheduled for the 
system being simulated. Each of these events on the event list may schedule other future 
events or may change the state variables of the system, or both. 

The simulation clock controls the execution of the events stored on the event list. 
The clock moves in discrete blocks of time from the first event on the event list to the 


next. The simulation performs no work between events scheduled on the event list, 
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instead the clock “jumps” from the current time to the time of the next event. When the 
simulation clock jumps to the next time for which an event 1s scheduled the events 
scheduled occur, have their effect on the system, and are then removed from the event 
list. The simulation clock then moves to the next time for which events are scheduled. 

The first step in simulating a system with the discrete-event approach ıs to define 
the state variables needed to descnbe the system to be simulated. Once the state variables 
have been defined, the next step 1s to determine all of the events that cause the state 
variables to change. This process requires careful analysis of the system at ıts most basic 
level. As asimple example, imagine simulating a queue of people. The single state 
variable that describes a queue is the number of people in the queue. There are only two 
events that can change the state variable: another person joins the queue, or a member of 
the queue leaves. At the most basic level then, a queue can be described by a single non- 
negative number which can be change by only two events. 

One very useful technique to support this decomposition and to aid in the 
description of discrete-event simulations 1s the use of an Event Graph. Event Graphs 
were introduced by Schruben in Simulation Modeling with Event Graphs [Ref. 14] and 
further discussed by Buss in Introduction to Event Graphs [Ref. 15]. An Event Graph is 
a directed graph consisting of nodes and edges. The nodes of the Event Graph indicate 
the events of the discrete-event simulation and the edges are used to schedule future 
events. The edges of the Event Graph may include a scheduled time delay and can also 
have a Boolean condition controlling the scheduling of the future event. 

Figure 7 captures the essence of the event graph. When event A occurs, event B 
is scheduled with a time delay of tpejay from the current time, if the Boolean condition 1 is 
true. In the case where the Boolean condition is false the event is not scheduled. 
Described in the context of the event list, when event A occurs at time ta and 1 1s true, 
event B is added to the event list at time tg = ta + tpetay. The state variables of the system 
change only at the nodes of the graph, which represent the events that are capable of 
changing the state variables. These changes to state variables can be listed below the 
node in simple cases. More complex models may have too many state changes to 


explicitly list each and every one below its associated node. 


2) 


Figure 7. The basic Event Graph construct. From [Ref.14]. 


Event Graphs will be used in this thesis to describe the simulation model. Two 
additional features of the Event Graph are used in this thesis: these are canceling edges 
and the passing of parameters along edges. Canceling edges are depicted by dashed lines, 
and indicate that the occurrence of event A causes the removal of the next scheduled 
occurrence of event B from the event list. Passing parameters allows information about 
the current state to be passed to future events. An event that expects and requires a 
parameter has the type of parameter (i.e. int, double, Mover) in parentheses below the 
event name. Any scheduling edge involving a passed parameter has the name of the 


parameter inside a box in the edge. 


B. SIMKIT 


Simkit is a simulation tool that utilizes the Java programming language to build 
discrete-event simulations. Simkit has three major underlying themes that will be 
described below: loosely coupled components, the listener pattern, and control of 
information. 

Simkit simulations are closely related to the Event Graph. Recall that the nodes 
of an Event Graph correspond to the events that describe the system. The Java methods 


written in a Simkit simulation have roughly the same name as the events on the Event 
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Graph. The word “do” ıs simply added to the beginning of the event name to form the 
method name. For example, the Simkit code written to implement Figure 7 would have 
two methods, do A and doB. 

The scheduling arcs of the Event Graph are incorporated into Simkit by use of a 
“waitDelay” statement inside a “do” method. The “waitDelay” statement includes the 
name of the event to be scheduled, the time to delay before executing the event, and any 
parameters to be passed to the future event. An example of a completed Java method for 
the Event Graph in Figure 7 1s as follows. 


Pipe | 
PER 


waitDelay (B, tDelay); 


Similarly, the canceling edges of the Event Diagram are incorporated into Simkit 
by use of an “interrupt” statement inside a “do” method. The “interrupt” statement 
includes the name of the event to be canceled and any parameters to be passed to that 
event. 

Simkit has a small suite of components ready-made for discrete-event simulation. 
Examples of these components include a Basic Mover and a Cookie Cutter Sensor. The 
Basic Mover moves from one point to another using instantaneous constant velocity. , 
When a Basic Mover reaches the point it was moving to, it stops and does nothing else 
unless some external entity provides a new destination. The Cookie Cutter Sensor is a 
sensor with radial range of R. The sensor detects targets closer than R units away with 
probability 1 and detects all other targets with probability O. 

Simkit is based on the concept of loosely coupled components. That is to say that 
each modular component is responsible for executing its own simple task and typically 
requires no knowledge of the source of its inputs or what 1s done with its outputs. For 
example, the Basic Mover moves to whatever coordinates it 1s told to move to with no 


concept of the reason why. 
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The key to control of the entities in Simkit is the event listener paradıgm. The 
listener construct is to register certain entities as listeners of other entities. After this 
registration, the listener entity will “hear” whenever the listened-to entity executes a 
method. In those cases where the listener has a method of the same name as that just 
executed by the listened-to entity, the listener's method will also be executed. For 
example, an entity named a Mover Manager may be registered to listen to a particular 
Basic Mover. When the Basic Mover executes its doEndMove method, the Mover 
Manager will “hear” the doEndMove method of the Basic Mover and will execute its 
own doEndMove method. 

Another key basis for Simkit is the control of information. The thesis Sensors in 
Object Oriented Discrete Event Simulation [Ref. 16] contains a discussion on the reasons 
to control access to information in a simulation. These reasons include memory savings, 
greater fidelity to reality, and robustness [Ref 14]. Simkit approaches this need to control 
information by use of Referees. The purpose of the Referee is to arbitrate the interactions 
among entities in the simulation. Multiple Referees may be required in keeping with the 
loosely coupled nature of Simkit, with each Referee being responsible for only one type 
of interaction. An example of the need for a Referee is the interaction between a Cookie 
Cutter Sensor and a Basic Mover. The Cookie Cutter Sensor needs only to know when a 
target has been detected; indeed, the sensor should specifically not know in the case that a 
target was close to entering detection range R but then stopped. Likewise, the Basic 
Mover has no reason to know that it has been detected by the sensor, nor to know that it 
is about to enter the sensor’s detection range. This interaction 1s controlled by a Referee 
that keeps track of the location of the Basic Mover and the Cookie Cutter Sensor. When 
the Basic Mover enters the detection range of the Cookie Cutter Sensor, the Referee 
notifies the Cookie Cutter Sensor of the location of the Basic Mover and tells the Basic 
Mover nothing about the existence of the sensor, thus maintaining the logical flow of 
information in the simulation. 

Chapter IV will describe the use of Simkit and event graphs to model the JTRS 


network. It will also discuss the scenario developed to exercise the model. 
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IV. DESCRIPTION OF MODEL AND SCENARIO 


This chapter gives a brief description of the model constructed to sımulate the 
Marine Corps C41 system in 2015. The chapter concludes with an explanation of the 
OMFTS scenario used to demonstrate the model and for analysis of bandwidth 
requirements. The aim of this chapter is to provide an understanding of the functioning 


of the model through descriptions the use of Event Graphs. 
A. MODEL DESCRIPTION 


The system to be modeled is similar to a civilian computer network, with the 
exception that the elements in this network move across a battlefield. Thus, there are two 
major functions captured by the model: the communication function and the movement 
function. In keeping with the loosely coupled philosophy, these functions are separated 
from each other to the greatest extent possible. However, since the functions of the 
network are strongly dependent on the actions of the movement components, they are 
more tightly coupled than most Simkit simulations. 

The simulation moves entities across the battlefield generating messages of 
differing priority, depending on the situation. A generated message must flow through 
the network to get to its intended recipient. Each entity has a limited amount of 
bandwidth available to transmit and receive messages and thıs available bandwidth 1s 
reduced as a function of the size of any messages being processed. 

When a message 1s transmitted to an entity that lacks the available bandwidth to 
receive that message (1.e. the entity 1s currently handling several earlier messages), that 
message will be “dropped”. That is to say that the receiving entity will not receive the 
message and will not know that it missed a message. However, the entities do have the 
ability to store both generated messages and previously received messages for later 
transmission. Since messages are stored only when an entity 1s fully occupied sending or 
transmitting, the number of messages waiting to be sent 1s a measure of the load on the 


network. Smaller queues indicate a smoothly functioning network, with bandwidth 
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capacity ın reserve, and longer queues indicate a network struggling to keep up with the 
flow of message traffic. 

Each entity keeps a lıst, known as the network, of all entities that should be part of 
the communications network. Each entity also keeps a separate list, known as the 
commList, of all other entities that it is currently in direct communication with. The sum 
of the information contained in the commLists of all entities describes the topology of the 
communications network at any given time. The network list is all those entities that 
should be able to get communications to each other across the network, while the 
commList is a subset of the network list of only those in direct, “one-hop” 
communication at a given time. The network list does not change throughout the 
simulation, while every commList 1s dynamic and does change as the scenario unfolds. 

If a generated message is intended for an entity on the generator's commList, the 
message is sent directly to that entity. If the recipient is not on the sending entities’ 
commList, an element on the commList is selected and the message is sent to that entity 
in the hopes that this new holder of the message will have the message’s recipient on its 
commList. This process is repeated until the message reaches the recipient. The strength 
of this system over current tactical communications is that one unit need not have direct 
communication with another in order to pass intelligence or request support; rather a unit 
only needs to know that the target of its message is a member of the network. 

Receipts are generated when a message reaches its recipient. Each receipt then 
transits the network back to the onginator of the message for which the receipt was 
generated. The receipt flows through the network using the exact same procedure as the 
original message, but may follow a different path to reach its destination. To avoid 
unnecessary and unrealistic network saturation, the size of receipt messages 1s set to 0.1% 
of the capacity of a JTRS. 

Each message transmitted has a predetermined delay time for retransmission. 
After that delay, the message will be retransmitted unless a receipt has previously arrived. 
This feature guards against the fact that a saturated network will drop some messages. 
The information passed in every message is considered important, so the model attempts 


to ensure that the information arrives where it 1s needed. 
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The network 1s made up of a series of objects of the type JTRS. Each JTRS 
represents the command and control hub for a particular military unit in the scenario. 
The JTRS object is a container for a collection of other objects. Among these are: 

l. ArrivalProcesses 

2. QueueManager 

3. Receiver 

4. Transmitter 

The listener pattern allows each component to perform its own unique function 
while getting information it needs from other JTRS components. It is necessary to have 
an understanding of the functioning of each component before discussing the actual 
listener pattern implementation of this model. 

The ArrivalProcesses associated with each JTRS are responsible for simulating 
the occurrence of an event requiring generation of a message at the unit. The JTRS has 
an array of ArrivalProcesses, one for each message priority level that exists at that 
particular JTRS. For example, in the case where a JTRS is capable of generating 
message of prionties Routine, Immediate and Flash, that JTRS would have three separate 
ArrivalProcesses. 

The ArrivalProcesses in this simulation assume that message arrivals constitute a 
Poisson process, and thus have exponential inter-arrival times. The model has the ability 
to change the arrival rate of the Poisson processes, depending on the combat situation of 
the JTRS. However, if further data collection by the Marine Corps indicates that a 
Poisson process is not the best way to model the arrival of messages in the C4I system, 
this model is capable of switching to the better distribution simply by replacing the 
current arrival processes with new ones. This is a case of increased flexibility thanks to 
loosely coupled components: The JTRS does not care what method the Arrival Processes 
are using to generate arrivals, only that an ArrivalProcess says “doArnival.” Figure 8 is 


the Event Graph (See [Ref. 13] and [Ref. 14]) of the ArnvalProcess. 
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Figure 8. Event Graph for ArrivalProcess. 


The QueueManager ıs responsible for sorting and storıng all messages waiting to 
be sent by the JTRS. Messages can be added to the outgoing queue for one of three 
reasons. The creation of a message by the JIRS causes that message to be gueued. The 
second event causing a message to be queued 1s the arrıval of a message destined for 
some other JTRS. The thırd way a message can be added to the queue ıs ıf amessage has 
been erroneously sent to the Transmitter without sufficient bandwidth to actually transmit 
the message. Figure 9 1s the Event Graph for the QueueManager. 

The QueueManager sorts messages first according to message priority and then 
by the time the message was generated, known as the timestamp. Messages of higher 
priority are placed in the queue ahead of all messages of lower priorities. In the case of 
messages with the same priority, the message with the earliest timestamp enters the queue 
in front of all those with later timestamps. 

Whenever the bandwidth available to the JTRS increases, or a message 1s added 
to the queue, the QueueManager checks the queue for messages to be sent. A message 
can be sent if its bandwidth requirement is less than the bandwidth available to the JTRS 
and the message does not have special instructions to be sent only at a later time. The 
QueueManager steps through the queue until either a message that can be sent or the end 
of the queue 1s reached. If the queue contains a message that can be sent, the 
QueueManager removes that message from the queue and sends it to be transmitted, 
which in turn causes the available bandwidth of the JTRS to be decreased. The 


QueueManager then checks the queue again, comparing message sizes to the current, 
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decreased bandwidth available. This process is continued until the queue ıs empty or the 
QueueManager reaches the end of the queue without finding a message to send. That is 
to say, until all messages in the queue have been sent to be transmitted, or until there are 
no messages in the queue that can be transmitted with the bandwidth remaining. 

The final function of the QueueManager is to remove specific messages from the 
queue when told to do so. The model's usage of this function 1s to remove messages 
scheduled for retransmission at a later time if a receipt for that message arrives before the 


retransmission time. 
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Figure 9. Event Graph for QueueManager. 


The Receiver class receives messages from transmitters within communication 
range of its JTRS. Upon arnval of a message, the Receiver notifies the JTRS of the size 
of the message. This causes the bandwidth available to the JTRS to be immediately 
decreased by the size of the message. The Receiver also causes the JTRS to schedule the 
return of the bandwidth committed to receiving the message after a time delay equal to 
the time spent receiving the message. Figure 10 is the Event Graph for the Receiver. 

Each received message is categorized by the Receiver as one of the following 
types: 
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1. For this JTRS and as a receipt for a previously sent message. 
2. For this JTRS and not as a receipt. 
3. Not for this JTRS. 


A message of type | causes the Receiver to notify the QueueManager to remove 
the message scheduled for retransmission from the queue. A message of type 2 causes 
the Receiver to generate a receipt and to send the receipt to the QueueManager for 
addition to the queue. A message of type 3 1s sent immediately to the QueueManager. 

The Transmitter object gets messages from the QueueManager and broadcasts 
them to Receivers within communication range. Each message sent to the Transmitter is 
evaluated to ensure the JTRS has sufficient bandwidth to send the message. If the 
bandwidth available is greater than that needed to send the message, the Transmitter send 
the message to one of the Receivers within communication range. The Transmitter picks 
a Receiver to send to by first checking to see if any elements on the commList are the 
intended recipient of the message, in which case the Transmitter sends to that Receiver. 
If the message’s recipient is not on the commList, the Transmitter arbitrarily picks a 
Receiver on the commList and sends the message. The Transmitter takes exactly the 
same steps as the Receiver to help the JTRS keep track of current bandwidth available. 
Figure 11 1s the Event Graph for the Transmitter. 

In addition to containing the above components, each JTRS also handles three 
specific functions. The first of these 1s to generate message objects when the 
ArrivalProcess has an arrival. The second function of the JTRS ıs to track its own 
bandwidth available. This 1s done by listening to the Receiver and Transmitter as they 
announce the size and duration of each message. The final function 1s to accept changes 
to the situation by changing the arrival rates of the ArrivalProcesses. This function 
allows the simulation of differin g intensities of action and combat. The Event Graph for 


the JTRS is shown in Figure 12. 
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Figure 10. Event Graph for Receiver. 
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Figure 11. Event Graph of Transmitter. 
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Figure 12. Event Graph for JTRS. 


Figure 13 shows the listener pattern used by the network. Information flows in 
the direction of the arrows, that is the object at the point of the arrow is the listener and 
listens to the object at the origin of the arrow. The plain bold arrows indicate how the 
components of a single JTRS interact. The bent arrow indicates a listener pattern set up 
between JTRSs. Each Receiver is a listener to all Transmitters of the JTRSs on the 
Receiver’s JTRS’s commList. This enables the transmission of messages between the 


elements of the network. 
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Figure 13. Listener pattern for communication network. 


The movement of the JTRS sets around the battlefield 1s accomplished by 
associating each JTRS with a unique Mover object. The JTRS in effect “rides” on the 
Mover. The following are two additional objects conned in the JTRS: 

1. CommMover 

2. BasicSensor 

The BasicMover is a class provided in Simkit and moves only in a straight line 
from one point to another, with instantaneous and constant velocity. The BasicMover is 
provided a destination by another Simkit class, the PathMoverManager. Once the 
BasicMover arrives at its destination it announces doEndMove, which 1s heard by the 
PathMoverManager, who in tum passes the next point for the BasicMover to move to. 
The PathMoverManger is provided by the user a list of coordinates which describe the 
path of the BasicMover. Once the PathMoverManager stops sending new coordinates to 
the BasicMover, the mover stops. 

The network topology is described by the sum of the information contained in all 
of the commLists maintained by the JTRSs in the simulation. The JTRS keeps track of 


its own commList by using an extension of another Simkit process. 
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Simkit comes equipped with the BasicSensor, which ıs a cookıe cutter sensor, as 
discussed in Chapter II]. The BasicSensor is built to locate Movers, of which 
BasicMover is a sub-class, and so can be detected. Simkit also includes a Referee class to 
keep track of interactions among entities, and a CookieCutterMediator to mediate the 
interactions identified by the Referee. | 

The Referee and the CookieCutterMediator ensure that no undeserved 
Information ıs passed to either the Mover or the BasicSensor, in keeping with the 
information protecting principle of Simkit. Specifically, any Mover detected by the 
BasicSensor is not passed directly to the BasicSensor, rather a new object called a contact 
is passed to the BasicSensor. This prevents the BasicSensor from having access to the 
methods and variables of the Mover, as could be the case if an actual reference to the 
Mover was passed instead of the contact. These contacts are recorded by the BasicSensor 
on a DetectionList. The Referee and CookieCutterMediator together keep the 
BasicSensor's DetectionList up to date, adding contacts as they enter range and removing 
contacts from the līst as they exit range. 

The nature of this problem is somewhat different in that the JTRSs are 
cooperative and, once in range, they will want to share their identities in order to update 
commLists and pass messages. Three actions are required to change the existing Simkit 
methods to support this simulation. First, the CookieCutterMediator is extended by a 
new CommLinkMediator class. This new class passes an actual reference to the Mover 
detected by the BasicSensor, rather than a contact. Secondly, the BasicMover is extended 
by aCommMover class. This CommMover class differs from a BasicMover in that the 
CommMover 1s built to carry a JTRS and knows that it is associated with a particular 
JTRS. The association of an entity to a BasicMover, on the other hand is one-way only: 
the riding entity knows it is associated with a BasicMover, but the BasicMover does not 
know about its rider. The final step to maintaining the commList is for the JTRS to ask its 
BasicSensor for the sensors DetectionList. Because of the CommLinkMediator, this 1s 
actually a list of all CommMovers within range of this JTRS. Because these are 
CommMovers, and are thus aware of carrying a JTRS, they can report a reference to the 


JTRS they are associated with. The JTRS simply gets the DetectionList from its 
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BasicSensor, polls each CommMover on the DetectionList to leam the identity of the 
CommMover’s JTRS, and adds that JTRS to the commList. The Referee and 
CommLinkMediator will keep the BasicSensor’s contactList current and accurate, which 


will in tum allow the JTRS to keep an accurate commList. 
B. SCENARIO DESCRIPTION 


The simulation developed for this thesis 1s flexible enough to be applied to a 
myriad of communication networking situations. A single representative STOM scenario 
will be detailed in this section and the results of that scenario examined in Chapter V. 
The scenario 1s constructed to include all of the communications challenges of STOM 
and to fully exercise the simulation. 

The year is 2015 and a U.S. naval amphibious force is located off the coast of a 
hostile country, prepared to conduct operations in support of national interests. The 
landing force is composed of elements of the 8" Marine Regiment (MAR) and 2° Tank 
Battalion (2TkBn). All forces are equipped with WLAN at the company level and with 
JTRS for communication above the company level. Each battalion will conduct the 
attack with three companies on the ground, plus a battalion headquarters. For clarity the 
units are referred to by their battalion headquarters’ names, although all units would 
actually be task organized, with elements attached and detached as the situation indicates. 

The commander’s estimate of the situation, aided by national and theater level 
intelligence, is that the enemy will likely lose the will to fight if his capital is seized. As 
a result of this estimate, an operations order has been prepared, assigning 8" Marines the 
mission of seizing two objective areas. Objective A (OBJ A) is the capital itself and OBJ 
B 1s a military barracks that can be expected to attempt to reinforce the capital’s garrison 
force. 

The operations order calls for a supporting attack by 1" Battalion, 8" Marines 
(1/8) against OBJ B and the main attack by 2"? Tank Battalion (2TkBn) and 2" Battalion, 
8'" Marines (2/8) to seize OBJ A. The supporting attack is scheduled for 0100 local time, 


and must take place before the main attack on OBJ A starts. It is expected to take 90 
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minutes of combat to secure OBJ B to the extent that the main attack can hit OBJ A 
without fear of enemy reinforcements, and an additional 60 minutes to complete the 
seizure of OBJ B. Given that OBJ B cannot reinforce OBJ A, it is expected to take 90 
minutes of combat to defeat the garrison force at OBJ A. 

Table 1 lists friendly forces for this operation. The Trans column indicates which 
member of the mobility triad will be used for the Ship-To-Objective movement. In the 
case of the tanks, LCAC transportation will be used to get to the shore and from then on 
the mobility of the tanks themselves will be used. Speed refers to the expected rate of 
unopposed advance for each unit. Speed listed in the form speed]1/speed2 refer to the 


different speeds on water and on land, and can be read as waterspeed/landspeed. 


Nan Regina 


Table 1. Friendly forces. 8th Marines Headquarters will remain aboard shipping. 















Figure 14 is a rough diagram of the scheme of maneuver. The assault will come 
from over the horizon, keeping the support elements and shipping safe from land based 
threats. The amphibious force is currently approximately 50 nautical miles offshore. 
OBJ B, the military barracks is another 30 nautical miles inland, while OBJ A, the 
capital, is 125 nautical miles from the coast. | 

The JTRSs in this scenario have their maximum range set to 35 nautical miles. 
The extended distance of 175 nautical miles will require pre-planned relay stations in 
order to maintain communications. The 8" Marines Regimental Communications Officer 
has planned for a series of relay stations between the two objectives and the command 
element aboard shipping. The relay equipment and personnel will accompany the assault 
forces with the main attack, and will start relaying when the force arrives at each relay 


station's designated location. The relay stations in support of the attack on OBJ B will be 
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inserted prıor to the attack, thus ensuring that they will be ready to relay when the assault 
occurs. The coordinates of the Objectives, Amphibious Force, and the Relay Sites are 


listed in Table 2. 


Main Attack 





Figure 14. Ground Combat Element scheme of maneuver. 





Location 
Amphibious Force & 8” Marines (0.0, 0.0) 
Relay 1 CFFI 


Relay 2 (42.42 , 42.42) 
Relay 3 (63.63 , 63.63) 
Relay 4 (84.84 , 84.84) 


Relay 5 (106.05 , 106.05) 
Objective A (123.74,123.74) 
Relay 6 (23.1 , 13.33) 
Relay 7 (46.2 , 26.66) 


Objective B (69.28 , 40.0) 


Table 2. Location of Relay Sites and Objectives. 


Unit/Objective 
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The sımulatıon has a total of 13 entities on the battlefield, four per battalion and 
the Regimental Headquarters. There are three levels of communications intensity for 
each entity in this scenario. Each level of intensity 1s described by both the frequency of 
messages, and the urgency or priority of the messages generated. Frequency is a measure 
of the arrival rate of messages in the ArrivalProcess. The urgency of messages is a 
description of the distribution of messages between the priority levels modeled 

The first communication intensity level, low intensity, is low frequency, low to 
middle priority. This level is the default at the start of the simulation and is the level of 
Intensity expected during an unopposed movement, where messages are infrequent and of 
aroutine nature. The second level, middle intensity, corresponds to a tactical movement 
to contact, in which the unit is covering previously unseen terrain and is unsure of the 
location of the enemy. Messages are more frequent than the first level, but retain the 
same proportions of arrival. 

The last and highest communications intensity, high intensity, is high frequency 
and high priority. This is the level that reflects a unit in actual combat. Message arrival 
rates peak and the priority of these messages 1s very high. Very few low priority 
messages are even generated, which is an attempt by the simulation to model the real 
changes that occur on communication networks when engaged in combat. Table 3 details 
the interarrival times sent to the arrival processes. 

In this scenario each battalion is assumed to have the same communication 
intensity throughout its sub-units. Its possible to set each entity’s communication 
intensity individually. However, for the sake of simplicity in the scenario, each battaljon 


changes communication intensity as a whole. 
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Communications Intensity Message Pniority Mean Interarrival 


Time (Minutes) 





Table 3. Interarrival times of messages. Model varies times as intensity changes. 


All units start the simulation at the low intensity setting. First Battalion, 8" 
Marines, the unit conducting the supporting attack on OBJ B, remains at low intensity 
until landing on OBJ B, at which point the unit changes to high intensity. The main 
attack changes to mid intensity once landfall 1s made and the movement to OBJ A begins. 
Upon reaching OBJ A, the main attack’s intensity changes to high intensity. The 
headquarters element’s intensity level is set to be the maximum intensity level of any 
subordinate unit. 

All units start collocated with the Regimental Headquarters. 2/8 in AAAVs 
moves first, followed by 2TkBn on LCACs, phased so that both forces arrive at the beach 
at the same time and location and can move toward OBJ A together. 1/8’s attack on OBJ 
B 1s scheduled for 0100 and the main attack is scheduled for 0300. This timing allows a 
30-minute delay beyond the 90 minutes predicted for 1/8 to accomplish its mission while 
seeking to maximize the confusion of the enemy by nearly simultaneous attacks. Table 2 


shows the scenario’s assault timeline. 
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Time Event 








1930 2/8 starts movement to shore 


2TkBn starts movement to shore 
2/8 and 2TkBn ashore, starts movement to OBJ A 
1/8 starts movement to OBJ B 


Assault on OBJ B 


Expected conclusion of battle on OBJ B 


Assault on OBJ A 


Expected conclusion of battle on OBJ A 


Table 4. Assault timeline. 










The scenario will be simulated from the movement of the first unit to the expected 
conclusion of the battle on OBJ A. 

The MOE for the scenario 1s a weighted penalty function assigns a cost for each 
late message. The Penalty Function assigns a base cost of one to a late low priority 
message. A late middle pnority message is three times as costly, and a late high priority 
message is five times as costly, as a late low priority message. The model also defines 
late differently for each priority of message, as indicated below: 

PENALTY P = 5*H + 3*M + 1*L 

Where H = Number of high priority Mss not delivered within 1 minute. 

M = Number of middle priority messages not delivered within 3 minutes. 


L = Number of low priority messages not delivered within 10 minutes 


A special purpose Java class, PenaltyCalculator was constructed to manage the 
MOE. The count of late messages ıs tracked during the simulation scenario by 
calculating the time to delivery of each message that arrives at the Receiver of the JTRS 
that 1s the target of the message. If the current simulation time minus the timestamp of 
the message minus the transmission time of the message exceeds the delivery threshold, 
the PenaltyCalculator 1s notified and records the late delivery. The Penalty Function only 


considers those messages sent between 8" Marines and the three battalion headquarters in 
4] 


computing the count of late messages. Intra-battalion messages do not count against the 
systems performance. 

After the simulation is complete, the queue of each QueueManager is checked for 
undelivered late messages and the PenaltyCalculator updates the MOE. The final Penalty 
is reported at the end of the scenario. 

The effects of varying the bandwidth of the relay sites will be examined by 
observing corresponding changes in the Penalty Function. Due to the lack of good 
communications data, this bandwidth is described as a multiple of the bandwidth 
associated with anormal JTRS node. In other words, two relay sites might be described 
as having bandwidth of 1.0 and 1.5 respectively, which is to say that the first relay site 
has the same bandwidth as all non-relay JTRS nodes in the network, while the second has 
150% of the bandwidth of non-relay nodes. 

The scenario will also be modified to examine the effects of parallel relay sites. 
This will be modeled by adding a second relay site at each relay position listed in Table 
2. The results of the basic scenario, along with this modification are presented in Chapter 


V. 
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V. SCENARIO RESULTS 


The reason for developing this simulation was to examine the bandwidth 
requirements of the JTRS in support of a STOM scenario. It was believed that the relay 
sites in the scenario would be the weak links in the communication network. The actual 
results of the simulation do not support that belief. The surprising result was that the 
effectiveness of the network, as measured by the penalty function, was relatively 
insensitive to the bandwidth of the relay sites. This chapter will explore both the results 
of the scenario and will use a simplified expected value analysis to examine these 


counter-intultive results. 
A. BASIC SCENARIO 


The model was extremely sensitive to the arrival rates of messages. The arrival 
rates used in the scenario were decided upon by testing the network when all units were 
co-located and so were assured of being able to reach the target of any message in one 
hop. The network held up under low and mid communications Intensity levels, but 
queues built up when set to the high intensity level. This queuing was a desired feature 
of the model and is intended to portray the stress of combat on the network. 

No matter what arrival rates were presented to the model, it remained insensitive 
to relay bandwidth. The Penalty Function rises when more messages arrive in the system 
and falls when the arrival rate 1s lower, but within each arrival rate the Penalty Function 
remains insensitive to relay bandwidth changes. 

The value gained from the model is exactly that 1t did not behave as expected. 
This caused additional examination of the system being modeled and the model being 
used. Detailed, but of course less than exhaustive, exploration of the model’s behavior 
indicates that it is behaving as descnbed in Chapter IV. 

In testing the effects of relay bandwidth on the penalty function, a total of 20 trials 
were run at each of several relay bandwidth level. Columns two and three of Table 5 
show the mean and standard deviation of the penalty function at the bandwidth level 


indicated in column one. Column four is a nonparametric approximate 90% confidence 
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interval for the median based on the binomial distribution, as described and tabled in 
Practical Nonparametric Statistics [Ref. 17]. Figure 15 is a graphical depiction of the 
point estimators of the mean penalty function at each level of bandwidth. 

Special attention is drawn to the case in which relay bandwidth was set to 0.0. 
The Penalty Function in this case is calculated from the total number of messages 
generated when relay was required. During significant portions of the scenario the two 
battalion headquarters and 8!" Marines were within radio range of each other and so did 
not require relay. The results in Table 5 seem to indicate that the Penalty Function 
variations between the bandwidth levels is a result of noise in the simulation and not 


because of any response change as a result of relay bandwidth changes 


Relay bandwidth Mean Penalty S.D. of Penalty 90% CI for median of Penalty 

.5 
l 
Z 
5 






















a 
AA 
895500 8 
se 


Table 5. Results of simulaton runs. 





A nonparametric median test was performed [Ref. 17] on the six bandwidth 
levels. The purpose of the median test is to determine if several samples came from 
populations having the same median [Ref. 17], which ıs the null hypothesis. If the null 
hypothesis is not rejected in this case, 1t would indicate that the Penalty Function 
variations observed in the simulation runs are a result of normal random fluctuations in 
the simulation, rather than a change in the underlying distribution. 

The procedure calls for pooling all data and determining the median of that group, 
which 1s referred to as the grand median. Each sample is then divided into two groups: 


those observations above the grand median and those at or below the grand median. The 
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number from each sample 1n either group (above median or not) are then tabled. See 


Table 6 for the results from the simulation output. 


Mean Penalty Function Value 


Z 3 4 
Relay JTRS bandwidth 


Table 6. Median Test cell counts. 4 





When a=b, as in this case, the test statistic T for the Median Test is computed as 


follows: 


= 5 (C7 = Da 
i=1 n 


Where: 
c 1s the column, or population from which a random sample was drawn. 


Ox; 1s the number of observations in row ] or row 2 in column i. 
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n; is the size of the random sample drawn from the i"\ population. 
In this case all n; = 20. 


Under the null hypothesis that the samples all come from populations with the 


same median, T is distributed is as follows: o ER 


The test statistic is 3.45. The p-value for a result of 3.45 from a Chi-squared 
distribution with 6-1=5 degrees of freedom is .6309. Therefore we can not reject the null 
hypothesis that the six samples came from distributions with the same mean. 

Both Table 5 and Figure 15 indicate that significant changes to the relay 
bandwidth do not cause corresponding significant changes to the penalty function. There 
are two possible explanations for this model behavior. Either the model is not correctly 
simulating the true nature of the system, or the real system may behave this way. It is 
likely that both of these possible explanations are at least somewhat true and in 
combination yield this surprising result. 

It is possible that the simplistic message routing scheme and description of 
bandwidth used in this model may be causing behavior that 1s not consistent with the real 
system. The system being simulated is so large and has so many actions and interactions 
that some level of abstraction 1s necessary in order to produce a simulation that can be 
run on a desktop computer. 

The results of the parallel relay system are actually worse than for single relays. 
This too may be caused by the way ın which the model picks where to route messages; 
parallel relay sites allow more choices for routing and increase the probability that a 
message will go the “wrong” direction. Given the model’s demonstrated insensitivity to 
any changes in relay bandwidth, it should not be surprising that adding bandwidth to the 
relay positions did not help the Penalty Function at all. 

Regardless of this result, a parallel relay system 1s more robust than a single relay 
system in real-world operations. Equipment failures and enemy actions can be expected 
to occasionally cause the loss of a relay site to the network. In the single relay system, 
this has the potential to cause elements of the network to be isolated from the rest of the 
network if the failure occurs at a key relay node. The primary factor favoring the single 
relay system is cost. If system A has half the bandwidth capacity of system B, but costs 
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75% of the cost of B, then A will never be favored from a financial standpoint; simple 
algebra tells us that each “unit” of bandwidth is 50% more expensive for system A than 
for system B. Because of this financial unattractiveness, system A 1s unlikely to be 
selected as the system of choice, despite the tactical flexibility and robustness it brings. 
It is remains possible that the real network itself may be fairly insensitive to relay 
bandwidth, especially at the high intensity communications level. This possibility is 


examined in the next section. 
B. SPECIAL CASE ANALYSIS 


Each battalion headquarters in the scenario 1s dealing with a higher headquarters 
and three subordinate units. It 1s not unrealistic to believe that in high an intensity penod 
of combat that the battalion headquarters will be the limiting nodes, rather than the relay 
sites. The battalion headquarters are dealing with frequent and urgent exchanges of 
information between themselves and three subordinate units, as well as equally frequent 
and urgent exchanges with the regimental headquarters. On the other hand, the relay sites 
are only handling the traffic between battalion and regimental headquarters and are not 
producing any bandwidth-reducing messages of their own. Once the battalion 
headquarters is saturated, the Penalty Function climbs, regardless of the performance of 
the relay suites. This may be a case of the simulation accurately modeling the system 
under study, despite the original expectations of the modeler. j 

An analytical examination of the normal scenario is not possible; but in a special 
case, the nature of the arrival processes can be exploited to gain some insight into the 
relative traffic load at specific nodes in the network. This case is the one in which the 
probability that a unit (other than 8 Marines) sends a message to its own higher 
headquarters is 1.0. This probability was set to .5 for all units except 8 Marines for the 
basic scenario, and is changed here for purposes of analysis. 8" Marines continues to 
send messages to any member of the network with equal probability. 

A further simplification made for purposes of analysis is that each element sends 


messages along the correct edge for ıt to reach its target. Thıs ıs not how the model 
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works, but will provide for ease of analysis. Figure 16 is the approximate topology of the 
network when the battle at OBJ B is underway. Arrows indicate the flow of messages as 
required by the 100% -to-headquarters rule. Note that 1/8 and ıts subordinate units are all 
in range of Relay 102. 

We will examine the relative loads on 1/8 and Relay 102. Because 1/8 1s in 
combat, intensity is set to high for 1/8 and 8" Marines. No messages from 2TkBn or 2/8 
will reach Relay 102 or 1/8, because they will all be sent to a battalion headquarters or 
the 8" Marines. 

The interarrival times for high communications intensity are: .3,.6, 6.0 (minutes) 
for high, mid, and low priority messages. We will aggregate all messages into a single 
arrival rate. The arrival rate of the Poison process is 1/(interarrival time). That means 
that we can expect each non-relay JTRS to produce: 


60(1/.3 + 1/.6+1/6.0) = 310 messages per hour 





Figure 16. Network topology during the battle for OBJ B. 


8"" Marines will pick message targets at random, with probability 1/3 that it will 
send a message in the direction of 2/8 (4/12 possible targets in that direction). 1/4 of the 
messages from g'" Marines will be for First Battalion, 8" Marines, for a cumulative 
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fraction of 1/12 of the messages from 8 Marines expected to be sent through Relay 102 
to 1/8. 

Relay 102 will also have 100% of the messages from 1/8 sent through itself on 
their way to 8 Marines. The expected total load on Relay 102 will be 335.8 messages 
per hour (13/12 * 310). 

1/8 produces its own 310 messages per hour on average. It 1s also the target of 
100% of all three subordinate units” traffic (an expected additional 930 messages per 
hour). Add to this the 310/12 messages expected to arrive from 8th Mannes and the total 
expected load for 1/8 1s 1265.8 messages per hour. This 1s over 3.7 times the load on 
Relay 102. 

This example gives some insight into why the model is behaving as itis. The 
bandwidth limiting element of the network is not the relay, it is the battalion 


headquarters. 
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VI. CONCLUSION AND RECOMMENDATIONS 


This thesis set out to examine the effects of changing relay suite bandwidth in a 
JTRS network. A discrete-event simulation model was developed to model the system 
and was implemented in Java using Simkit. The results of the simulation indicate that the 
JTRS network performance, as measured by timely arrival of messages, is insensitive to 
even large changes in relay suite bandwidth. 

The simulation model produced for this thesis has been demonstrated and has 
performed correctly in those cases tested. Correctly, in the case of the model”s 
performance, means only that the model functioned as designed, not that 1t was a perfect 
representation of the as-yet-nonexistent JTRS communication network. This thesis has 
built a base upon which further improvements can be bullt. 

Time did not permit the author to make all of the enhancements to the model that 
had originally been planned. Several key areas for further research are message routing 
schemes, different abstractions of bandwidth utilization, and implementation of terrain 
effects modeling. 

Messages are currently randomly routed to a member of the sender's commList. 
The only firm restriction to this is that a message will not be routed back to the entity that 
sent 1t to the current holder. This prevents “ping-ponging” of messages back and forth 
between two entities in communication with each other but who are in communication 
with no other entities. However, messages tend to spend extra time in the system due to 
the simplicity of the routing system. A smarter implementation might be to poll members 
of the commList to determine 1f any of them have the messages recipient on their own 
commList. In this case the message would be sent to the first member reporting 
communication with the recipient. Alternatively, a shortest path algorithm could be 
implemented to pick the best feasible route from sender to target. 

Bandwidth utilization in this model is purely a function of message size. The 
message takes up a portion of the JTRS’ s bandwidth proportional to its size and keeps 


that bandwidth tied up for a time also proportional to the message’s size. For example, a 


51 


message of size .1 (or 10% of a JTRS bandwidth), will take 10% of the sender’s 
bandwidth for .1 minute, likewise as message of size .2 will take 20% for .2 minutes. No 
matter whether the JTRS has 100% of its bandwidth available or only 20%, the message 
takes the same amount of time to transmit. A scheme could be developed to treat 
bandwidth in a way that reduces the time spent in message transmission if the JTRS has 
additional bandwidth available. This could easily be accomplished by assigning each 
message a weight base on the its size and assigning each radio a maximum weight 
capacity per time period. This suggested method is similar to, but simpler to implement 
than, the packet system of data transmission, in which every message 1s broken down into 
like sized packets that are then individually routed to the target. 

A last major enhancement is the introduction of terrain effects. The model 
currently does not take terrain in to account when determining the commList. Instead, 
the cookie cutter approach is taken: if another unit is with the user selected radio range, 
then that unit is added to the commList. This does not model the effects of terrain on 
radio wave propagation, which can and do cause very large variations from nominal radio 
ranges. 

The single major recommendation is one that was identified early in the research 
for this thesis. This recommendation is that the Marine Corps take steps to capture its 
actual bandwidth requirements and usage. This needs to be done in order to properly 
apply the power of modeling and simulation to our C4I architecture, and to ensure we 
procure C4] systems that will serve our needs into the future. Data on the frequency of 
occurrence of messages and the size of those messages is a critical first step in 
determining what the C4] architecture of the future needs to be able to do. 

In conclusion, this model helped to gain insight into a JTRS network by giving 
unexpected and counter-intuitive results, which in tum caused a deeper examination of 
the system under study. Upon further examination, these results make sense and are the 
valid results of the model, rather than of logical or syntactical errors in the programming. 
The implication of the results of this thesis is that the battalion headquarters are the 
bandwidth bottlenecks in the network. It is, therefore, at the battalion level that 


bandwidth should be increased in order to improve network performance. 
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APPENDIX A. JAVA CLASSES DEVELOPED FOR THIS THESIS 


1. CommMover. This class extends the BasicMover of Simkit. Moves a JTRS and can 
report which particular JTRS it is associated with. 


2. CombatManager: This class controls the changes in unit speed and communication 
intensity throughout the scenario. 


3. CommLinkMediator: Extends the CookieCutterMediator. Modifies the 
CookieCutterMediator to allow sensors to have a reference to the target, instead of a 
surrogate. This removes the information hiding feature of the CookieCutterMediator, but 
allows the JTRS to keep a CommList. 


4. JTRS: This class 1s the heart of the model. Each instance creates 1ts own 
ArrıvalProcesses, QueueManger, Receiver, and Transmitter. 


5. Message: Thıs class keeps track of ıts own sıze, transmission time, target, sender, and 
the JTRS that most recently transmitted 1t. Messages are the objects passed around the 
network. 


6. MessageComparator: This class sorts Messages for the QueueManager, ensuring 
that Messages are put ın the proper queue position. 


7. PenaltyCalc: This class listens to all Receivers to hear Message arrivals. Tracks the 
number of late Messages of each priority and returns the Penalty Function value when 
asked. 


8. QueueManager: This class puts Messages on, and removes Messages from the 
Queue. Sends Messages to the receiver when bandwidth is available. Receives 
generated Messages from the JTRS and received Messages from the Receiver. 


9. Receiver: This class listens to all Transmitters on the JTRS commList and receives 
Messages intended for its JTRS. 


10. TestScenario: This 1s the test program that makes that sets up and runs the 
sımulatıon of the scenarıo. 


11. Transmitter: This class is responsible for picking a member of the commList and 


then sending the Message to that member. Receives Messages for transmission from the 
QueueManager. 
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